More precisely, the invention relates to a radiocommunication module. Remember that the radiocommunication module is an essential element of a radiotelephone. It hosts and executes a main software (commonly called “radiocommunication software” or “GSM software”) that in particular performs wireless communication functions (radiocommunication) and controls various other hardware elements (screen, keyboard, loudspeaker, etc.) of the radiotelephone.
Normally (first application), the radiocommunication module is included in a terminal (or ME for “Mobile Equipment”) that cooperates with a SIM (Subscriber Identity Module) card.
Other applications are now envisaged for the above mentioned radiocommunication module.
In particular, it has been proposed to integrate the radiocommunication module in devices other than radiocommunication terminals but that still require a wireless communication function (second application). For example, telemetry devices (for reading meters), alarm devices or bank card readers.
It has also been proposed to supply the radiocommunication module in independent form (third application); it is then qualified as a modem. This type of modem does not contain any hardware man-machine interface element (screen, keyboard, loudspeaker, etc.). It is designed to cooperate with a terminal equipment (supporting a client software), that does have hardware man-machine interface elements. In particular, but not exclusively, the terminal equipment may be a micro-computer. In general, the terminal equipment hosts and executes a client driver software that controls the radiocommunication module, using a set of driver commands in the AT format. The AT (for ATtention command) commands enable the Terminal Equipment (TE) to request the radiocommunication terminal to which it is connected to perform some predetermined actions. To achieve this, the main software (hosted on the radiocommunication module) comprises means of executing AT commands sent to it by the client driver software (hosted on the terminal equipment).
For further information about AT commands, refer firstly to the ETSI “GSM 07.05” and “GSM 07.07” standards, and secondly to the ITU-T recommendation V25ter which are inserted herein by reference.
In general, a radiocommunication module can be driven by a terminal equipment using AT commands not only within the framework of the above mentioned third application (radiocommunication module forming a modem), but also within the context of the first and second applications mentioned above (radiocommunication module included in a radiocommunication terminal or other system).
In other words, regardless of what application is envisaged, the radiocommunication module may be driven by a terminal equipment with which it cooperates (usually through a serial link). In this case, a client driver software (comprising a “client external application”), hosted and executed by the terminal equipment, sends AT commands to a main software, hosted and executed by the radiocommunication module, so that the radiocommunication module can execute them.
As shown in FIG. 2, operation of the existing technique used for terminal equipment to drive a radiocommunication module may be summarized as follows:                step “1”: the client external application (client driver software) 2 sends an AT command;        step “2”: the serial link 5 transmits the AT command to the AT command execution means 4 included in the main software 3 hosted and executed by the radiocommunication module 1;        step “3”: the execution means 4 execute the AT command;        step “4”: after execution, the execution means 4 send an AT response to the client external application 2;        step “5”: this response is sent through the serial link 5;        step “6”: the client external application 2 receives the response.        
Each of these steps is shown in FIG. 2 by a circle in which the number of the step concerned is entered. The same convention is adopted in the following figures related to this invention (and that are described in detail in the remainder of the description).
The existing technique for driving a radiocommunication module by terminal equipment has several disadvantages.
Firstly, it requires two sets of resources (processor and memory). The radiocommunication module comprises a processor and a memory (first set of resources) and the terminal equipment also has a processor and a memory (second set of resources). Therefore, the existing technique mentioned above is expensive in terms of equipment and energy consumption.
Another disadvantage of the above mentioned existing technique is that the radiocommunication module is entirely driven by the terminal equipment. The client driver software hosted on and executed by the terminal equipment is the “master”, while the main software hosted and executed by the radiocommunication module, is the “slave”.
In order to overcome these disadvantages with the state of the art, the applicant (Wavecom Company) deposited a French patent application No. FR 0103909 on Mar. 22, 2001 entitled “Radiocommunication module hosting and executing a client software, and corresponding process for use of a client driver software”. This application FR 0103909, the texts and the drawings of which are inserted herein by reference, proposes a new technique for driving a radiocommunication module consisting of hosting at least one client software on the radiocommunication module to act as a client driver software and/or to act as a client supervision software.
Thus, if the client embedded software acts as a client driver software, the radiocommunication module operates independently and inexpensively. In this case, the radiocommunication module does not need to cooperate with a terminal equipment, and the main software and the client driver software use the same resources (same processor and same memory).
Furthermore, if the client embedded software acts as the client supervision software, the radiocommunication module is not restricted to acting as a slave with respect to the terminal equipment that executes the client driver software. The client supervision software is executed by the radiocommunication module, and manages the driving requested by the client driver software and executed by the terminal equipment. In this case, it will be noted that the client embedded software is software that is additional to the state of the art configuration mentioned above. However, this additional software is inexpensive because it uses the same resources (processor and memory) as the main software also hosted by the radiocommunication module.
In one preferred embodiment of the new technique mentioned above:                the main software comprises particularly a binary file containing the main application;        the client software comprises particularly a first binary file containing the client application, and a second binary file (for example in the form of a previously compiled library) containing an interface application between source functions associated with the client application, and execution functions associated with the main application.        
This new technique for driving a radiocommunication module may be seen as a software platform, to enable clients to develop their own client applications and to download them in radiocommunication modules.
In the preferred embodiment mentioned above, the main software and the interface application are “proprietary” binary files developed by the radiocommunication module manufacturer, while the client application is a “client” binary file developed by the client.
Remember that the process for development of a binary file comprises the following steps:                write source files, for example in the “C” language;        compile these source files, so as to generate object files (in machine language for the microprocessor located on the radiocommunication module);        link edit the object files (compiled source files) so as to generate a binary file (that is then downloaded in the radiocommunication module).        
In the context of the above-mentioned new technique for driving a radiocommunication module, the purpose of this invention is to facilitate the task of the client in the development process of a client application.
Another purpose of the invention is to propose a simple and efficient solution to dialogue problems between applications (main and secondary client) that result from use of the general concept of this invention.
We will now briefly mention two known techniques of solving dialogue problems between two applications, with the disadvantages of each.
According to a first known technique, dialogue problems between two software applications are solved during link editing. But this makes it necessary to know all dialogue points. Furthermore, exchanging all dialogue source functions between two applications makes it necessary for each application to adapt to the other. The result is that the developer of one application (secondary application) must write a different version of this application for each client that wants to integrated it into his applications (main applications).
A second known technique of solving dialogue problems between two applications consists of using mechanisms such as dynamic link editing. With this type of mechanism, only the functions actually used have to be loaded into memory. For example, this technique may be DLL (Dynamic Link Library) used in Windows (registered trademark). Unfortunately, this technique requires large amounts of memory and is unsuitable for use when there are severe constraints in terms of CPU, memory and real time in radiocommunication modules.